In recent years, information handling has become a common task when dealing with a centralized computer networked to hundreds of terminals in remote locations. Despite the many advancements when dealing with large quantities of information being networked to numerous users, few systems have dealt with the enormous quantity of information that the airline industry deals with on a daily basis. Arguably, no other information handling system is more critical to the financial lifeline of developed countries; more vulnerable to peak periods during times of crises, such as war, natural disaster or labor strikes; or more inflexible when it comes to requiring the safe handling of critical flight information.
The largest such information handling system is owned by and operated by AMR Corporation. The host computer and the world-wide network is trademarked as Sabre Systems. The Sabre System comprises six (6) IBM model ESA 9000 mainframe computers and two (2) IBM model 300 which handle an astonishing 3920 messages per second. The communication network is linked to some 300,000 end users. As can be expected, not all 300,000 possible users desire or are entitled to the same priority when peak periods demand an assessment and implementation of prioritized use. Such, peak periods include times of strike, war, natural disaster and holidays. Unfortunately, systems are not designed to handle peak loads, but instead are designed to handle normal or regular capacity of information handling. Therefore, when peak periods arrive it is necessary to prioritize the users and handle the information in a manageable manner. This prioritization is necessary to insure that certain users that demand immediate access or service obtain such, while at the same time creating a system that is fair to other users which likewise need service.
In the past, the industry has recognized the need to have prioritized users. Unfortunately, the common method for prioritizing users was by line staging system which is performed at the front end of a host computer. Unfortunately, having the line staging being performed at the front end severely constrains any functional limitations. Front end staging can only stage an entire line not individual drops on a line. Therefore, if a line included one critical drop among several non-critical drops, the entire line was marked as critical. This system, therefore, did not permit a precise and efficient method for separating the critical from the non-critical users. In practice, well over half of the users were designated as critical and there was little attempt at distinguishing the degree of criticalness or a priority within groups considered critical users.
Therefore, a need has arisen for a host computer staging system which stages and determines the priority of each terminal by a terminal address. In addition, a need has arisen for a non-frontend processor staging system in order to have access and ability to determine priority with respect to each terminal rather than each line. In addition, a need has arisen for a system which is not shut down an entire office at one time, but instead permits each location to have some limited access to the centralized computer system. In addition, a need has arisen for an interactive system which can signal the user that the staging process is in place, having a planned duration of such staging, and which permits the lower prioritized user to plan their day accordingly. Furthermore, a need has arisen for a staging system which is controlled by the host computer rather than by a front-end processor or a network. Furthermore, a need has arisen to have a degree of predictability for each user by having a predetermined priority for each terminal by the designation of a prioritized terminal address. Finally, a need has arisen for a system which operates efficiently and cost-effectively in an industry which handles millions of transactions daily in an effective and expeditious manner.